MEX best practice #23
Conversation
|
This will require internal MathWorks review before it's merged into main. |
There was a problem hiding this comment.
Looks good.
I'm glad this is its own standalone document and not part of the main Toolbox Design doc.
At the top, maybe give etymology of MEX as "MATLAB EXecutable file".
"Let's explore the world of MEX integration!" This sounds a little too ChatGPT chirpy.
Maybe mention earlier that the actual compiled MEX files themselves are derived via the build process and so don't even appear in the folder. We only see, for example, subtract.m and subtract.cpp.
We should be clear about the fact that derived files shouldn't be checked into revision control. The whole concept of derived files is alien to a lot of our pure MATLAB users (i.e. they never really trained on any other language or language ecosystem).
Typo? line 47 "mex function" => "MEX function"?
|
@bpancras All these changes look good to me. |
…ndation to create a "derived" folder in place of the private folder solution to address AndyC feedback.
…ubfolder> under <folder>" * Added a "don't assume performance is better" comments to mex.md * Draft integration of mex.md file references into the main README.md * Minor editorial
|
OK, here's what I believe to be a near-complete proposed version that addresses add internal and external feedback. Key items:
Tagging @colbysparks in case he wants to look at it again. |
Tweaked recommendation around end users calling your MEX file. I removed the discussion of performance and wrappers. I think the recommendation is strong enough as worded - don't let users call your stuff directly. It's obvious that this means it's only called from your toolbox code. Readers should then be able to infer that if they want to give the MEX functionality directly to end users, they should wrap a MATLAB function around it to handle arguments safely. And there's nothing to suggest that they should create a wrapper function just if they are calling within their own code.
|
@michellehirsch -- your change looks good. Thanks. Any comments, @bpancras, @gulley , or @acampbel ? I'm going to move forward with the merge EOD (Natick) Wednesday 9/10. |
|
LGTM |
The proposed organization is meant for toolboxes that implement MEX functions using C/ C++/ Fortran for implementing features. They might also interface with external libraries.